✨ Allow appealing a moderator decision through special report type #1969
Conversation
There was a problem hiding this comment.
(didn't code-review, just lexicon and behavior review)
Having some last-minute indecision about the "who can create an appeal for who" behavior, but I think how this PR implements it is fine, I don't have a specific alternative to propose, and we can probably change our minds later.
| @@ -64,6 +64,10 @@ | |||
| "type": "boolean", | |||
| "description": "Get subjects that were taken down" | |||
| }, | |||
| "appealed": { | |||
There was a problem hiding this comment.
I still think this should probably be openAppeal or currentAppeal or something more specific. I wouldn't strong-block on this but think it is the kind of thing where a good name reduces confusion the need to dig in to docs.
There was a problem hiding this comment.
This does mirror the name of the new field on subjectStatusView. Do you think it should be updated there too?
There was a problem hiding this comment.
yh we also use terms like takendown for boolean flag fields so at least it's consistent. happy to rethink naming in a future pass but I think I'd want to move forward with this as is.
lexicons/com/atproto/admin/defs.json
Outdated
| "lastAppealedAt": { | ||
| "type": "string", | ||
| "format": "datetime", | ||
| "description": "Timestamp referencing when the owner of the subject appealed a moderation action" |
There was a problem hiding this comment.
It is a small nit (could ignore this comment), but "owner" feels subtly weird to me here. We use "author" just below, that feels better. Or "creator".
| // Exit early if someone is trying to game the system by appealing someone else's content | ||
| if (isAppealEvent && createdBy !== subjectDid) { | ||
| return null | ||
| } | ||
|
|
There was a problem hiding this comment.
This is the part i'm still least sure of myself, even after settling on this behavior after earlier discussion. It feels a little weird to special case like this (and re-write the createdBy elsewhere).
I think it's probably fine though, and changing the behavior probably won't be a change to Lexicons so we aren't particularly locked-in to these behaviors ("who can create appeal reports").
There was a problem hiding this comment.
Agree, I think we can iterate on it. We might be able to push it up into authorization layer then forget about it here.
lexicons/com/atproto/admin/defs.json
Outdated
| "takendown": { | ||
| "type": "boolean" | ||
| }, | ||
| "appealed": { | ||
| "type": "boolean", | ||
| "description": "True Indicates that the a previously taken moderator action was appealed against, by the author of the content. False indicates last appeal was resolved by moderators." |
There was a problem hiding this comment.
| "description": "True Indicates that the a previously taken moderator action was appealed against, by the author of the content. False indicates last appeal was resolved by moderators." | |
| "description": "True indicates that the a previously taken moderator action was appealed against, by the author of the content. False indicates last appeal was resolved by moderators." |
This PR implements a very basic mechanism for allowing users to appeal a moderator decision, leveraging existing lexicons and infrastructure. The expected user flow, through this feature is
appealedtotrueon the moderation_subject_status rowmodEventResolveAppeal